home *** CD-ROM | disk | FTP | other *** search
- Path: cstatd.cstat.co.za!not-for-mail
- From: vincer@iaccess.za (Vince Risi)
- Newsgroups: comp.lang.ada,comp.lang.c++,comp.lang.c,comp.lang.modula3,comp.lang.modula2,comp.edu,comp.lang.eiffel
- Subject: Re: Hungarian notation
- Date: 5 Jan 1996 09:58:32 +0200
- Organization: Internet Africa public service
- Message-ID: <E/56wg2yqXwB083yn@iaccess.za>
- References: <30C40F77.53B5@swsbbs.com> <marnoldDJEvtJ.1Lx@netcom.com>
- <6sp2wg2yqLwd083yn@iaccess.za> <4cbkr9$5h2@preeda.internex.net.au>
- NNTP-Posting-Host: minnie.iafrica.com
-
- In article <4cbkr9$5h2@preeda.internex.net.au>,
- sultan@connexus.apana.org.au (Jon Hornstein) wrote:
- > In article <6sp2wg2yqLwd083yn@iaccess.za>, vincer@iaccess.za says...
- > >
- > >In article <ou91k2jozn.fsf@i486.mcneil.com>,
- > >sean@mcneil.com (Sean McNeil) wrote:
- > >
- > >This kind of code....
- > >
- > >> /* if the branches are of the same kind... */
- > >> Branch brFirst= abrBranches[ixbrFirst];
- > >> Branch brSecond= abrBranches[ixbrSecond];
- > >> if (G_brKind(brFirst) == G_brKind(brSecond) &&
- > >> /* ...and the same destination... */
- > >> G_brDest(brFirst) == G_brDest(brSecond))
- > >> {
- > >> /* do something useful with the parallel edges */
- > >> ...
- > >
- > >written as
- > >
- > > Branch Branch1 = Branches[First];
- > > Branch Branch2 = Branches[Second];
- > > // if the branches are of the same kind...
- > > // ...and the same destination...
- > > if (KindBranch(Branch1) == KindBranch(Branch2) &&
- > > DestBranch(Branch1) == DestBranch(Branch2))
- > > {
- > > // do something useful with the parallel edges
- > > ...
- > > }
- > >
- > >is far more readable, with strong typing there would be warnings
- > >if things were used incorrectly.
- > >
- > >Vince
- > >=====
-
- > My experience, in the spirit of hungarian notation, is that it gives
- > consistent clues to the type and declaration of a declared variables.
-
- Which is also its main weakness. There are many types of integers and
- floats. Each has its own prefix and when it comes to porting code
- or writing portable code then these become a real pain in the butt.
-
- > I've
- > developed a consistent naming convention which includes hungarian notation
- > prefixes and and then noun combinations and perhaps a postfix to declare all
- > my variables.
-
- Exactly you have developed your own naming convention.
-
- > These variables may be quite large but thats never been a
- > consideration when it comes to finding errors.
-
- > Branch1 and Branches is too confusing as a token. The information content in
- > the name is quite small.
-
- It is perfectly adequate. In English and I presume American Branches means
- a collection on more than one branch, and Branch1, Branch2 are equally as
- expressive. I have no idea if Branch1 is supposed to be FirstBranch and
- Branch2 is supposed to be NextBranch. I am not at all intimate with the
- algorithm, I was just supplying a reasonable facsimile of what was
- presented previously with HN.
-
- > I inferred from the name that it has something to
- > do with a generic branch. I would not add a generic hungarian prefix to
- > infrequently used types as they may cause confusion with the standard set of
- > tokens as used to define type.
-
- > For example Branch1 could become br1, but thus could infer a boolean real 1
- > nonsense! My preference would be FirstBranch with no hungarian prefix!
-
- > So instead of
-
- > Branch Branch1 = Branches[First];
- > Branch Branch2 = Branches[Second];
- > ...
- >
- > I may name it
- >
- > BRANCH FirstBranch = aBranches[FIRST_E],
- > NextBranch = aBranches[SECOND_E];
- >
- > // if the branches are of the same kind...
- > // ...and the same destination...
- > if (SameBranchType(FirstBranch) == SameBranchType(NextBranch) &&
- > SameBranchDestination(FirstBranch) == SameBranchDestination(NextBranch))
- > {
- > // do something useful with the parallel edges
- > ...
- > }
- >
- >
-
- Why capitalize BRANCH? Is this part of the same plot that defines int INT,
- long LONG, double DOUBLE, ...?
-
- All in all, lets agree to disagree on coding style.
-
- Vince
-